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Reports on Computer Science and 
Technology 



The National Bureau of Standards has a special re- 
sponsibility within the Federal Government for com- 
puter science and technology activities. The programs 
of the NBS Ir^t-tute for Computer Sciences and Techno- 
logy are designed to provide A DP standards, guidelines, 
and technical advisory services to improve the effective- 
ness of computer utilization in the Federal sector, and 
to perform appropriate research and dsvolopment ef- 
forts as foundation for such activities and programs. 
This publication series will report these NBS efforts to 
the Federal computer community as well as to in- 
terested specialists in the academic and orivate sec- 
tors. Those wishing to receive notices of publications in 
this series should complete and return the form at the 
end of this publication. 
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BACKGROUND 



This Guide provides answers to sixty-four key questions 
about software maintenance. It is designed for Federal 
executives and managers who have a responsibility for 
the planning and management of software projects. It 
is also intended for Federal staff members affected by, 
or involved in, making software changes and who need 
to be aware of steps that can reduce both the difficulty 
and cost of software maintenance. 

Issues addressed in the Guide include the feasibility 
and applicability of software reuse, the development of 
maintainable software, as well as the improvement of 
existing software, achieving programmer and software 
productivity, and the three key attributes of maintain- 
able software: correctness, understand abili v , and relia- 
bility. Finally, it discusses software tools that can aid 
in making existing code more maintainable. The ques- 
tion arid answer format is used to organize the material 
in a concise manner that represents a general approach 
for evaluating software maintenance problems and al- 
ternative workable solutions. 



UNDERSTANDING SOFTWARE 
MAINTENANCE 



1. WHAT IS SOFTWARE MAINTENANCE? 

Software maintenance is the performance of those ac- 
tivities required to keep a software system operational 
and responsive after it is accepted and placed into pro- 
duction. It is the set of activities which result in 
changes to the originally accepted (baseline) product 
set. These changes consist of modifications created by 
correcting, inserting, deleting, extending, and enhanc- 
ing the baseline system. 
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2, WHAT ARE THE TYPES OF SOFTWAR 
MAINTENANCE? 



The three types ^ftware maintenance are perfectiv 
adaptive, and corrective. 

3, WHAT IS PERFECTIVE MAINTENANCE! 

Perfective maintenance includes all changes, insertion 
deletions, modifications, extensions, and enhancemen 
which are made to a system to meet the evolvii 
and/or expanding needs of the user. They are general 
performed as a result of new or changing requirement 
or in an attempt to augment or fine tune the softwar 
Activities designed to make the code easier to unde 
stand , such as restructuring or documentation updat 
(often referred to as ff prevent iv e" maintenance), a 
considered to be perfective. Optimization of code 1 
make it run faster or *^e storage more efficiently is al 
included in the perfective category. Estimates ind 
cate that perfective maintenance comprises appro* 
mately 60% of all software maintenance efforts. 

4. WHAT IS ADAPTIVE MAINTENANCE? 

Adaptive maintenance consists of any effort which 
initiated as a result of changes in the environment i 
which a software system must operate. It accounts f 
about 20% of all the software maintenance effort 
The environmental changes are normally beyond tl 
control of the software maintainer and consist primal 
ly of changes to the: 

o rules, laws, and regulatio is that affect 
the system; 

o hardware configurations, e.g., ne\. terminals, 

local printers; 
o data formats, file structures; and 
o system software, (e.g., operating systems, 

compilers), utilities. 
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5. WHAT IS CORRECTIVE MAINTENANCE! 

Corrective maintenance refers to changes necessitated 
by actual errors (induced or residual "bugs") in a sys- 
tem. It accounts for 20% of all the software mainte- 
nance efforts and consists of activities normally con- 
sidered «<> be error correction required to keep the sys- 
tem operational. The key causes for corrective mainte- 
nance are design errors, logic errors, and coding errors. 
Design errors ?re generally the result of incorrect, in- 
complete, or unclear descriptions of the system change 
being requested, or a misunderstanding of the change 
request. Logic errors are the result of invalid tests and 
conclusions, faulty iogic flow, incorrect implementation 
of the design specifications, or unusual combinations of 
data, which were not thoroughly tested. Coding errors 
are generally caused by the programmer and are the 
result of either incorrect implementation of the detailed 
logic design, or the incorrect use of tne source code log- 
ic. 



6. WHAT IS MAINTAINABILITY? 

Maintainability refers to the effort required to find and 
fix or modify an error in operational software. Main- 
tainability examines the effects of software failure, and 
ways to minimize those effects. In order to maintain 
control over the software maintenance process, and to 
ensure that the maintainability of the system does not 
deteriorate, it is important that software maintenance 
be anticipated and planned. The quality and maintai- 
nability of a software system often decrease as the syv 
tern grows older. This is the result of many factors 
which, taken one at a time, may not seem significant 
but become cumulative and often result in a sybtem 
which is very difficult to maintain. Quality ">rcgram- 
ming capabilities and techniques are readily * /ailable. 
However until a firn: discipline is placed on how 
software maintenance v> performed, and that discipline 
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is enforced, many systems will be permitted to 
deter 1 orate to the point where they are impossible to 
maintain. It is likely that as the software maintaina- 
bility is improved, the capacity to handle additional 
changes will increase 

7. WHAT IS THE " REQUIREMENTS TO 
RELEASE" CONCEPT? 

Generally, changes are made in order to keep the sys- 
tem functioning in an evolving, expanding user and 
operational environment. When software maintenance 
is performed as an iterative development process, the 
concept of requirements to release can be applied. This 
concept presumes that whenever a modification is made 
to the software system, a functional review is made to 
determine if a corresponding change is needed any- 
where else in the system This review should, as a 
minimum, include an assessment of the software 
design, code, test data, and associated documentation 
products. 



8. HOW CAN "REQUIREMENTS TO 
RELEASE" HELP TO IMPROVE THE 
SOFTWARE MAINTENANCE PROCESS? 

A significant portion of the activities performed in 
software maintenance environments is reactive. As a 
result, there is often a tendency to zero in on the im- 
mediate problem, fix it and wait for the next problem 
to arise. If an examination is made of the functional re- 
quirements, there is a likelihood of gaining a better 
perspective on the problem, and its s jlntion. 

fl. HOW IS SOFTWARE MAINTENANCE 
CURRENTLY PERFORMED? 

In many organizations, software maintenance is still 
performed with second generation tools, using second 
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generation techniques. There are indications, however 
that managers are adopting and enforcing the use of 
improved techniques and practices. Standards and 
guidelines which provide guidance on how to ^prove 
software quality have been published by NBS, IEEE, 
and the DOD. 

10 WHAT IS THE RELATIONSHIP 
BETWEEN SOFTWARE QUALITY AND 
SOFTV/ARE MAINTENANCE? 

Softw vre quality ca'i be chara.terixed by such attri- 
butes as reliability, unJerstandability, testability, 
modularity, and expandability, all of which make the 
software more maintainable. Thus, software quality 
and maintainability are inextricably bound together. 
The greater the number of quality attributes en- 
gineered into the software during development the 
higher the degree of confidence in its maintainability. 
Although it is significantly easier to build quality into 
the software it can also be improved during mainte- 
nance. The cost of adding quality to existing software, 
however, is considerably more expensive. 



11 WHAT IS THE RELATIONSHIP 
BETWEEN SOFTWARE TESTING AND 
SOFTWARE MAINTENANCE ? 

Testing is performed to find errors and omissions. It ii 
also performed to ensure that the logic and structure o 
the software are appropriate. The more thorough th< 
unit, integration, and system testing, the more likel; 
the software will be reliable and correct. Consequently 
testing provides assurance that the activities c 
software maintenance have been performed correctly. 
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COSTS 



12. WHAT IS THE COST Of SOFTWARE 
MAINTENANCE? 

Software maintenance represents 60%-70% of the total 
cost of software which runs into the tens of b'ilions ol 
dollars each year. Perfective maintenance (changes, 
enhancements, extensions, etc.) comprises approximate- 
ly 6C% of the software maintenance costs. Adaptive 
maintenance and corrective maintenance are each ap- 
proximately 20% of the total. 

IS, CAN SOFTWARE MAINTENANCE 
COSTS BE REDUCED? 

While tota' software costs have risen rapidly, the ratio 
of development to maintenance costs has remained re- 
latively constant. This is a result of the growing 
dependency of many organisations on software, the ex- 
tended life of software, and the increasing complexity 
and size of many applications. 

Continued advances in modern programming technolo- 
gy (e.g. modern software engineering tools and 
methods, fourth generation languages, application gen- 
erators, etc.) will permit more sophisticated systems to 
be built at less cost. The dichotomy of this situation is 
that the more useful a system, the longer it will be 
used and the more it will cost over its lifetime. Thus, 
for some software, the cost over the total software life- 
time may actually rise, but the cost per year will de- 
crease 



14. WHAT CAN BE DONE TO BRING 
SOFTWARE MAINTENANCE COSTS 
UNDER CONTROL? 

The most important piece in the puzzle of controlling 
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total software costs is strong, effective management of 
the entire process The greater the discipline invoked 
in the software maintenance process, ♦.he higher the 
quality of software which will result 

The Federal Govern rr.ent continues to custom develop 
more than 90?6 of its software. Reuse of existing 
software, including the use of off-the-shelf packages, 
can help hold down costs. Other solutions, such as the 
use of non- procedural languages; greater use of modern 
software engineering technology, tools and methods; 
and the institution of more effective management con- 
trol also offer opportunities to bring the cost of 
software maintenance under control. 



15. SHOULD AN ORGANIZATION HAVE A 
SOFTWARE MAINTENANCE POLICY? 



Yes, a software maintenance policy is a vital step in 
controlling software maintenance costs. The policy 
should describe in broad terms the responsibilities, au- 
thorities, functions, and operations of the software 
maintenance organization. 



16. WHAT TYPE OF PERSON IS NEEDED 
FOR SOFTWARE MAINTENANCE? 

The person needed in a software maintenance environ- 
ment should be highly skilled and able to perfoiai a)) of 
the functional activity that occur during the software 
lifecycle. The person should be experienced, and have 
j good analytical capabilities. Above all, these people 
should be disciplined and thorough in their approach to 
analysis, coding, debugging, testing, and documenta- 
tion. 



PERSONNEL 
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17. WHAT SPECIFIC EXPERIENCES AR] 
NEEDED FOR SOFTWARE MAINTENANCE 

It is essentia) that software maintainers have experi 
ence working on tasks individually, as well as in team* 
The person should have had a major responsibility fc 
the completion of 

soir>e of these tasks It is important that the perso 
have a breadth of knowledge about software manage 
roent 

since in a maintenance environment, anything tha 
can go wrong usually does As a minimum, the perso 
should have a number of years experience working: 

o independently, 
o as part of a team, 

o with specific languages and computers, 
o with modern programming practices, 
o on various types of applications. 

18. WHY DO SOFTWARE MAINTAINER 
HAVF A HIGHER RATE OF TURNOVE1 
THAN OTHER A.DP PERSONNEL? 

Maintainers tend to change jobs at a higher rate tha 
other ADP professionals primarily because of the imag 
of maintenance. In many organizations, the traditioi 
ally held view that maintenance requires less aptitud 
than development is quite common. As a result, worl 
ing conditions, including remuneration, tends to be lei 
for maintainers than for developers. Within the ne» 
few years, this situation should change as increasin 
numbers of manager? recognize the value of the mail 
tainer to the daily operation of the organization. 
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SOFTWARE REUSE 



19, WHAT IS REUSABLE SOFTWARE? 



The popular notion of software reuse focuses on the 
software's source and object cod'*. While source and 
object code can be reused, software consists of more 
than just code Research has shown that greater 
benefits can be accrued through the use of the require- 
ments, specifications, design, documentation, test data, 
and other elements of the software 

20, CAN SOFTWARE REUSE IMPROVE 
SOFTWARE MAINTENANCE? 

Yes. In fact, software reuse should be at the heart of 
the strategy for software maintenance. Research has 
shown that the quality of software deteriorates when 
the only elements of the software that are reused are 
the source and object code. By effectively reusing th* 
requirements, specifications, design, documentation, 
test data, and other elements on which the code is 
based, the quality of the software can be 1 laintained, 
or even enhanced during the repeated modifications 
which occur after the software has been developed and 
placed into operational use 

21. HOW DO I RECOGNIZE THE OPPOR- 
TUNITIES FOR REUSE? 

Any time a new application is developed, or enhance- 
ments are planned for existing software, the first ques- 
tion which should be addressed is "Do softw£j*e ele- 
ments (requirements, specifications, etc.) exist which 
can oe reused in this application?" The type of 
s'Aware reuse that is practical in each situation varies. 
If a new application is being developed, the opportuni- 
ty to reuse elements from existing similar application 
ruid subsystems should be examined. When enhance- 
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rocnts are made to an existing application, existinj 
software elements should be used as the baseline when 
ever possible. Only when it is clear that reuse of exist 
ing software elements is inappropriate, should the deci 
sion be made to create brand new software elements. 



22. HOW CAN THE IMAGE OF SOFTWARE 
MAINTENANCE BE IMPROVED? 

Upper management must be kept informed of th< 
overall success of the software maintenance effort an< 
how software maintenance supports and enhances th< 
organization s ability to meet its objectives. Software 
maintenance is an important effort which supports an< 
contributes to the ability "f the organization to mee 
its goals. Too many ol the problems encountered ii 
software maintenance are the result of the negative at 
titude chat it is a function which exists because th< 
software support staff can "never do it right." Rather 
the emphasis should be on the corcept that softwan 
maintenance enables an organization to improve an< 
expand its capabilities using existing systems. 

The software maintenance manager has the responsibil 
ity for keeping the maintenance staff happy an< 
satisfied. Software maintenance must be thought of & 
thvi challenging, dynamic, interesting work it can be. 



23. WHAT ARE SOME OF THE ACTIONS 
THAT MANAGEMENT CAN TAKE TC 
DETERMINE WHEN TO CONSIDEI 
REDESIGN? 

A system which is w virtually constant need of corrcc 
tive maintenance is a prime candidate for redesign. A 
systems age and additional maintenance is perforate* 



MANAGEMENT 
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on them, many become increasingly fragile and suscep- 
tible to changes. The older the code, the more likely 
frequent modifications, new requirements, and enhance- 
ments will cause the system to break down. 

When a decision has been reached to redesign or to 
stop supporting a system, the decision can be imple- 
mented in a number of ways: support .an simply be re- 
moved and the system can die through neglect; the 
minimum support needed to keep it functioning may 
be provided while a new system is built; or the system 
may be rejuvenated section by section and given an ex- 
tended life. How the redesign is affected depends on 
the individual circumstances of the system, its operatr 
mg environment, and the needs of the organization it 
supports. 

24. HOW DO YOU DETERMINE WHEN TO 
ACQUIRE NEW SOFTWARE? 

Although maintenance is an ongoing procew, there 
comes a time when serious consideration should be 
given to acquiring new software. If there are require- 
ments for which the existing system is totally inade- 
quate or if the existing software is sufficiently outdated 
that the viability of the organization is affected, then 
consideration should be given to the acquisit'on of new 
software. 

A major concern of managers and software engineers is 
how to determine whether a software package will 
satisfy all of the existing requirements. In most cases, 
the software package handles only a part of the re- 
quirements. Thus, the acquired software package often 
will either have to be modified, or additional software 
will be needed. 
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25. WHAT ARE THREE KEY QUEST INS 
TO BE ANSWERED WHEN ACQUIRI1 ' A 
SOFTWARE PACKAGE? 

Organizations are acquiring boftware packages at an in- 
creasing rate. There are a number of questions that 
should be answered, however, the three that are 
perhaps the most crucial are: 

o How well can I use the software as it is? 
o How easy is the software to maintain? 
o Will I be able to use it if I change the 
processing environment? 

2ft. WHAT ARE SOME OTHER FACTORS TO 
CONSIDER WHEN SELECTING A 
SOFTWARE PACKAGE? 

o Does the purchase or lease agreement permit 

the purchaser to make modifications? 
o If not, are there adequate assurances that 

the seller of the package will make needed 

modifications? 
o Will the staff require training in order to 

understand, modify or test the software 

package? 

o If so, will the training be provided free 
or at an additional cost to the purchaser? 

For further detaib on the factors to be considered, se< 
(NBS114], [NBS88]. 

27. HOW DO YOU DECIDE WHETHER TO 
CONTINUE MAINTENANCE OR TO 
REDESIGN? 

The costs and benefits of the continued maintenance oi 
software which has become error- prone, ineffective 
and costly must be weighed against those of redesign- 
ing the system. While there ve no absolute rules Oi 
when to rebuild rather than maintain the existing s>* 
tern, some of the conditions that might lead to a deci 
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sion to redesign include: 



o Frequent failures 

o Cod? over seven-to-ten years old 

o Overly complex program structure and logic 

o Code written for outdated hardware 

o Running in emulation mode 

o Very large modules or unit subroutines 

o Excessive resource requirements 

o Hard-coded parameters that must be changed 

o Difficulty in keeping maintainers 

o Seriously deficient documentation 

o Missing or incomplete design specifications 

The estimated life cycle of a major application system 
is seven-to-ten years, although 15 to 20 year-old 
software systems are not uncommon. Software tends 
to deteriorate with age as a result of numerous fixes 
and patches. However, if the system was designed and 
developed in a systematic, maintainable manner, and if 
maintenance was carefully performed and documented 
using established standards and guidelines, it may be 
possible to run it efficiently and effectively for many 
more >ears. 

28. WHY SHOULD THERE BE A CENTRAL 
APPROVAL POINT FOR SOFTWARE 
CHANGES? 

A central approval point is essential to ensure that the 
desired changes are made to the appropriate software. 
One of the key problems in many software mainte- 
nance environments is inadequate control over the 
change process. 

2D. SHOULD DOCUMENTATION BE A CRI- 
TERION FOR PRODUCT COMPLETION/ 
DELIVERY? (PAY NOW OR PAY LATER) 

It is essential that the documentation be delivered as 
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part of the completed software product Without th< 
documentation, there is little assurance that th< 
software satisfies stated requirements or that the organ- 
isation will be able to maintain it. The cost of softwan 
maintenance is proportional to the effectiveness of th< 
documentation which describes not only what the sys- 
tem does, but the iogic used to accomplish its tasks. 

30. WHY SHOULD AN ORGANIZATION* 
HAVE A SOFTWARE MAINTENANCE 
STANDARDS POLICY? 

A software * ainte nance standards policy helps to en- 
sure software quality. Such standards describe in broac 
terms the responsibilities, authorities, functions, an< 
operations of the software maintenance oiganization 
The policy should be comprehensive enough to address 
any type of change to the software system and its en 
vironment, including changes to the hardware, software 
and firmware. To be effective, the policy should b< 
consistently applied and must be supported anc 
promulgated by upper management to the extent thai 
it establishes an organizational commitment U 
software maintenance. When supported by manage 
ment, the standards and guidelines help to direct atten 
tion toward the need for greater dif jipline in softwan 
design, development, and maintenance. 

31. WHAT ARE POME OF THE KEY ELE- 
MENTS WHICH SHOULD BE INCLUDED IIS 
A SOFTWARE PRODUCT RFP TO ADDRESS 
SOFTWARE MAINTENANCE? 

Too often, Federal managers are forced to accept 
software products which, in addition to be deliverec 
late, do not perform as required. An <xamination of th« 
RFP usually reveals that: 

o performance clauses were omitted; 

o software quality assurance plans were not 
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required; and 
o software configuration management plans were 
left to the discretion of the contractor. 



These are just a few of the elements that could help to 
prevent the delivery of defective, incomplete software 
products. 



32. HOW CAN MAINTAINABILITY BE BUILT 
INTO EXISTING SOFTWARE? 

There must be a program which has achieving main- 
tainable software as its sole objective. It should in- 
clude: 

o a plan for ensuring the maintainability 
requirements are specified into the software 
change design. 

o a measurement procedure to verify that 
maintainability goals have been met. 

o a performance review to provide feedback to 
managers, users, and maintainers on the 
effectiveness of the maintainability program. 

33. WHAT ARE SOME STEPS THAT CAN BE 
TAKEN TO HELP IMPROVE SOFTWARE 
MAINTENANCE? 

o Use high level languages 
o Use standard coding conventions 
(variable names, structures, etc.) 
o Use modular structures 
o Use meaningful comments 
o Use only standard compiler options 



TECHNICAL 
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34. WHAT CAN BE DONE TO TURN EXIST- 
ING SPAGHETTI CODE INTO UNDER- 
STANDABLE, RELIABLE SOFTWARE? 

Software maintenance is a labor intensive activity. 
Consequently, automated tools should be used whenev 
er possible. There are a number of structuring tools 
available that are designed specifically fcr reformatting 
and restructuring code. Some of these have been 
around for several years and thus, have a track record. 
For further details see (NBS88j. 

35. WHAT IS THE BEST MEASURE FOR 
DETERMINING IF THE QUALITY OF THE 
SOFTWARE IS DEGRADING? 

If changes to specific areas begin to occur more fre- 
quently, and require increasingly more effort to correct 
or modify, the software is probably degrading. This is 
particularly true if someone familiar with the code is 
making the changes. 

36. WHAT ARE METRICS? 

A metric is a measure of the extent or degree to which 
a product possesses or exhibits a certain characteristic 
for determining the value or level of effort required to 
perform a given function. 

37. HOW CAN METRICS BE USED TO IM- 
PROVE THE SOFTWARE MAINTENANCE 
PROCESS AND PRODUCTS? 

Currently, there are a number of metrics used to deter- 
mine productivity. Of these, Lines of Code is the most 
commonly used The complexity metrics can also be 
useful for determining how difficult a software change 
will be. Other metrics that can be employed include 
automated completeness and consistency checkers. Not 
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only can they be used to measure programmer produc- 
tivity, they can aid in understanding h^w *x>ftware 
changes affect the overall software systeoi from a main- 
tainability standpoint 



38. WHAT ARE THE KEY CONTRIBUTORS 
TO SOFTWARE MAINTENANCE COM- 
PLEXITY? 



o Deeply nested DO loops 

o Excessive IF statements 

o Excessive use of global variables 

o Excessive GOTO statements 

o Embedded parameters, literds, constants 

o Self- modifying code 

o Excessive interaction between modules 

o Multiple entry-exit modules 

o Redundant modules 



3«. WHAT ARE THE "DRIVERS" OF 
SOFTWARE MAINTENANCE? 

The primary driver of software maintenance is requests 
for enhancements. Other drivers include the poor con- 
dition of the code, scheduling, budget constraints, use 
of ineffective or outdated programming techniques, 
end tools 



40. WHAT ARE SOME SOFTWARE MAINTE- 
NANCE TECHNIQUES WHICH HAVE PRO- 
VEN TO BE USEFUL? 



o Top down programming 
o Stepwise refinement 
o Regression testing 
o Code walkthroughs 
o Codt audits/reviews 
o Peer reviews 
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41. IS DOCUMENTATION NECESSARY IN 
MAINTENANCE ENVIRONMENT? 



Documentation is valuable in both development and 
maintenance environments The level of documentation 
needed is a function of both the application and the 
maintenance environment For further information on 
documentation, see [FIPS38], [FIPS64], and [FIPS106]. 

42. AT WHAT POINT SHOULD DOCUMEN- 
TATION BE REQUIRED? 

Documentation should be required for each product 
deliverable, intermediate as well as final 



43. HOW SHOULD TEST DATA BE HAN- 
DLED? 

There should be a well-defined policy for generating 
and storing test data In some instances, it is prefer- 
able to use actual data rather than generated data. In 
either case, the user should help develop the test data. 
For further information on testing, 
see [NBS56], [NBS93], and [FIPS106] 

44. WHEN SHOULD FORMAL LIBRARY 
PROCEDURES BE USED: 

Microcomputers, especially when linked to mainframe 
computers, are making software systems increasingly 
accessible. One method of ensuring that the production 
or operational systems are not altered intentionally or 
unintentionally is to enforce formal library procedures. 
This usually can be accomplished by permitting ade- 
quate access to essentia) software and limited (read 
only) or no access to the operational software. 
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USERS 



45. SHOULD USERS BE INVOLVED IN DE- 
FINING OBJECTIVES OF 1HE SOFTWARE 
PRODUCT? 

The days of casting off the users as uninformed are 
past. In todays' environment, there is a general recog- 
nition that user input is essential. Whether it is as a 
member of the configuration control board or the audit 
and review team, the key u> producing a correct pro- 
duct is early user involvement 

40. WHY SHOULD USERS BE INVOLVED IN 
THE CHANGE PROCESS? 

Users have as much at stake as anyone in wanting the 
change to be implemented correctly. Therefore, their 
input should be solicited 

47. SHOULD USERS, MANAGERS, AND 
MAINTAINERS BE INVOLVED IN DECI- 
SIONS REGARDING SOFTWARE CHANGES? 

Yes. Too often the cause of software failure is due to 
inadequate communication between those who must 
use or are affected by the software change. A number 
of techniques can be employed to facilitate interface 
between users, maintained, and managers. They in- 
clude walkthroughs, configuration management control 
boards, audit and review teams, etc. 

48. WHY SHOULD USERS BE INVOLVED IN 
GENERATING TEST DATA? 

The users are more familiar with the data than the 
maintainer. While generated test data is useful, user 
generated, or live user data, is always preferable. 
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49. AS USERS ACQUIRE MORE AND MORI 
MICROCOMPUTERS AND ATTEMPT TC 
DO THEIR OWN PROGRAMMING, WILI 
THE SOFTWARE MAINTENANCE BURDErN 
INCREASE? 

Users do not always know in detail what they want un 
til they see a version of it, and then they want U 
modify. Unless t litre is close interaction between user 
and data processing personnel the gap between the» 
two groups will widen as users seek to handle more o 
their application development and maintenance. In th< 
short term, the burden will be somewhat lessened, bu 
as users experiment with more sophisticated packages 
the maintenance burden on the traditional data oro 
cessing departments is likely to increase. 

60, WHAT ARE SOME SUCCESSFUI 
SOFTWARE MAINTENANCE TOOLS? 

Tools that have been found to be effective include: au 
torn a ted restructure rs, debuggers, documenters, tes 
and program generators, editors, cross referencers 
software configuration management, and tracing tools. 

SOFTWARE CONFIGURATION 
MANAGEMENT (SCM) 



51. WFAT IS SOFTWARE CONFIGURATKW 
MANAGEMENT? 

Software Configuration Management (SCM) refers tc 
the control of software changes. It helps to ensure that: 

o all software change requests are handled 

accurately and completely; 
o the resulting products satisfy the 

specified requirements; 
o key software maintenance considerations, 
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responsibilities, and requirements are 
identified; and 
o the processing of software change requests 
(SCR) is facilitated. 



52. WHAT ARE THE SCM RESPONSIBIL 
TIES? 

SCM is responsible for configuration ideitific&tio 
configuration control, configuration status iiccountin 
auditing, records retention, disaster recovery, libra: 
activities, and coordinating the various activities wit 
the users, management, and the staff. 

5S. DOEF SCM APPLY TO THE SOURC 
CODE AND DOCUMENTATION? 

SCM should be applied to the k asek:ce documentatio 
as well as tne source and object ode. 

54. WHAT TOOLS SUPPORT SCM? 

There are a number of tools that are effective for SCA 
Most of these tools provide version control and/or ] 
brary and archival functions. However, there is a wi< 
range in the price of this class of tools. For moi 
specific information, see [NBS88]. 

55. ARE TOOLS ESSENTIAL FOR DviPLi 
MENTING SCM? 

Manually tracking software changes back to the r 
quire men ts and to other changes is a very labo 
intensive process. In a large application environmen 
with frequent changes, performing SCM manually ca 
prove to be quite difficult, if not impossible. 
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55. WHAT IS A CONFIGURATION CON- 
TROL BOARD (CCB)? 



The primary role of the configuration control board 
(CCB) is to facilitate software changes into the system 
The CCB should be comprised of representatives whc 
are involved in, or affected by, the software changes. 

57. WHAT ARE THE SPECIFIC DUTIES OF 
THE CCB? 

o Evaluate, assign, prioritize, and schedule 
software maintenance work requests. 

o Set the meeting time. 

o Establish the agenda to consider proposed 
software changes plans, procedures, and 
interfaces. 

o Inform the initiator of the software change 

request on the actions taken, 
o Track progress of all maintenance tasks and 

ensure that they are on or ahead of schedule, 
o Adjust schedules when necessary, 
o Communicate progress and problems to the user, 
o Communicate progress and problems to upper 

management, 
o Establish and maintain maintenance standards 

and guidelines, 
o Enforce standards and make sure that the 

software maintenance is of high quality. 



58. WHAT LEVEL OF FORMALITY IS NEED 
ED TO IMPLEMENT AN SCM PROGR> M? 

The level of formality depends on the environment 
There may be a CCB or an individual who functions z 
a CCB. The k*y is to assign the responsibility for er 
suring that the software changes satisfy the stated r< 
quirements before they are released for production. 
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TOOLS 



59. WHAT STEPS SHOULD BE TAKEN 
PRIOR TO SELECTING TOOLS FOR 
SOFTWARE MAINTENANCE? 

o There should be an inventory of the existing 
tools. 

o Current and potential use of the tools 

should be examined 
o An attempt should be made to acquire tools 

that are compatible with the existing 

en>! onment. 
o Training should be .onned for everyone who 

will either us* tools or be affected Dy 

thier use. 

50. WHAT SHOULD BE CONSIDERED 
WHEN SELECTING TOOLS? 

Many tools have been developed in a research environ- 
ment and used as prototypes to demonstrate concepts. 
They were never engineered as production products 
though they are being used as such. Ouch tools are 
generally not well documented, not efficiently coded, 
seldom portable, and often not adequately supported. 

51, WHAT IS AN INTEGRATED TOOL? 

An integrated tool generally refers to one that uses a 
common data base and/or a common command 
language for controlling and using a set of tools. The 
use of such tools may help to enforce uniformity within 
a software maintenance environment. 
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•2. HOW ARE SOFTWARE 
TOOLS CATEGORIZED? 



Software maintenance tools fall into seven categories: 

o Configuration management 
o Monitorirg/e valuation 
o Redesign 

o Code product ion /analysis 

o Verification/validation/testing (WT) 

o Tes ting/ i'lteg ration 

o Documentation 



•3. WHAT ARE SOME EXAMPLES C 
SOFTWARE MAINTENANCE TOOLS 1 
EACH CATEGORY? 

Configuration management: 

support library, status reporting 
Monitoring /evaluation: 

performance analyzers, automatic 

recovery tools 
Redesign: 

requirements analyzers 
Code production/analysis: 

structurer, debugger, comparator 
W&T: 

static an is, path analyzer 
Testing: 

test data generator 
Documentation: 

automatic documentor 
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64. CAN SOFTWARE MAINTENANCE BE 
CONTROLLED? 



In order to maintain control over the software mainte- 
nance process, and to ensure that the maintainability 
of the system does not deteriorate, it is important that 
software maintenance be anticipated and planned for. 
The quality and maintainability of a software system 
often decrease as the system srows older. This is the 
result of many factors which, taken one t a time, may 
not seem significant but become cumu.^ive and often 
result in a system which is very difficult to maintain. 
Quality programming capabilities and techniques are 
readily available. However, until a firm discipline is 
placed on how software maintenance is performed, and 
that discipline is enforced, many systems will be per- 
mitted to deteriorate to the point where they are im- 
possible *r» maintain. 

Software maintenance must be performed in a struc- 
tured, controlled manner. It is not enough to get a sys- 
tem w up and running* after it breaks. Proper manage- 
ment control must be exercised over the entire process. 
In addition to cont:olling the budget, schedule, and 
staff, it is essential that the software maintenance 
manager control the system and the changes to it. Sys- 
tems must no', only be developed with maintenance in 
mind, they must be maintained with maintainability in 
mind. If this is done, the quality and maintainability 
of the code actually can improve. 
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